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PREFACE 


This customer software release notice contains specific information 
for Release 8.32.03 of Wang Systems Networking (WSN) VS NETCORE. It 
provides an overview of Release 8.32.03 and describes hardware and 
software requirements, key enhancements, special considerations, and 
media contents. 

This document is intended as an aid to network administrators who are 
responsible for overseeing this release of the WSN VS NETCORE 
software. It also serves as an information bulletin for those 
interested in upgrading their present WSN VS network software. 

For additional information on WSN network configuration, control and 
monitoring, refer to the following documentation: 

• Wang Systems Networking VS Network Control and Monitoring Guide 
(715-0164A) 

• Wang Systems Networking VS Network Configuration Guide (715-0165A) 
The following related documentation may also be useful: 

• VS OFFICE Administrator's Guide (715-0850) 

• VS System Operator's Guide (715-0418A) 




CHAPTER 1 
INTRODUCTION 


OVERVIEW 

This chapter provides a brief description of the Wang Systems 
Networking (WSN) VS NETCORE, Release 8.32.03, package, and discusses 
the hardware and software requirements necessary to use the package. 


SUMMARY OF FEATURES 

WSN VS NETCORE is the software that enables multiple systems to 
communicate over a wide variety of transports, independent of the 
network topology in a WSN network. The software consists of programs 
related to the following operations: 

• Network operations and installation 

• Network configuration 

• Communications resource management of data links 

• Communications Network Services (CNS) 

• CNS management 

• Task invocation and connection management 

• Remote logon access 

• Network event logging 

• Problem diagnosis and correction 

A. major enhancement to WSN VS NETCORE, Release 8.32.03, is support for 
the Wang Professional Computer (PC) 200/300 Series, IBM PC AT/XT, and 
compatible PC systems to function as intelligent workstations 
connected by an 802.3 Local Area Network (LAN). Also included, is 
support for the new Wang VS 5000 Series. 

Other key enhancements include 

• CNS Manager (CNSMGR). CNSMGR is a new CNS network management tool 
that replaces the WSNMON utility used in previous WSN VS NETCORE 
releases. CNSMGR operates either independently or in conjunction 
with Wang Distributed Management Facility (DMF). 
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• The introduction of a new VS background task called Connection 
Manager (CNXMGR). CNXMGR provides connection services for 
intelligent workstation (IWS) systems on a local area network 
(LAN) that act as independent processors using the VS for resource 
sharing. 

• The addition of the program 0RATGATE to handle non-CNS logons from 
remote systems. 

• The addition of a new program called WSN Applications Manager 

(WSNAPPS), which enables you to include user-written, NAI-based 
applications in the WSN Directory. 


OPERATING PREREQUISITES 

Wang Systems Networking requires at least one transport product, 

WSN VS NETCORE, and one or more services or applications. 

WSN VS NETCORE software is installed by a Wang customer service 
representative at the customer site. Before you can use WSN VS 
NETCORE software, the hardware and software requirements discussed in 
the following sections must be met. 


Hardware 


The following hardware components are necessary to support WSN VS 
NETCORE, Release 8.32.03: 


• Any Wang VS system, except VS50, VS60, and VS80 (CP3 family). 
(WSN VS Standard Components, Release 8.21, remains available for 
VS50, VS60, and VS80.) 

• A minimum of two megabytes of physical memory to run CNS and 
related networking tasks. (Four megabytes or greater are 
generally recommended.) 

Additional hardware components are required that depend on the VS 
transport(s) being used (see Table 1-1). WSN VS NETCORE requires at 
least one WSN VS transport. Supported WSN VS transports are 


Information Distribution System BSC 
Information Distribution System SNA 
Multipoint Primary 
Multipoint Secondary 
Point-to-Point (Sync/Async) 1 


X. 25 

Local Communications Transport 
IEEE 802'3 
Wang Band 


Available separately for use with single-line or multiline 
telecommunication controllers. 
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Table 1-1 summarizes the hardware requirements and minimum VS 
Operating System release for each of the WSN VS transports. 


Table 1-1. Hardware, VS Operating System (OS), and Transport Support Matrix 






HARDWARE 

VS OS 



WSN VS 

TRANSPORTS 




Device 

Device 

Minimum 

Pt- 

-Pt 




IDS 


IEEE 


Number 

Type 

Release 

Sync 

Async 

MP-P 

MP-S 

WB 

SNA 

BSC 

X. 25 

802.3 

LCT 

22V26-1 

TC I OP 

7.13 


■ 





a 




22V26-2 

TC I OP 

7.13 


■ 





a 




22V26-3 

TC I OP 

7.13 


a 





a 




25V96-8, 

VS65 

7.13 

■ 

a 









-16 

MLTC 












22V96-8, 

VS85/100 

7.13 

■ 

a 









-16 

MLTC 












23V96-8, 

VS300/7000 

7.13 

■ 

a 









-16 

MLTC 












25V66 

VS5/6/15/65 
LAN Contrl 

7.13 









a 


22V66 

VS85/100 

LAN Contrl 

7.13 









a 


23V66 

VS300/7000 

LAN Contrl 

7.13 









a 


25V76-1 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 

a 



25V76-2 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 




25V76-1A 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 

a 



25V76-2A 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 




25V76-1B 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 

a 



25V76-2B 

TCDA 

7.13 

■ 

a 

a 

a 


a 

a 




CIU-A a 

External 

CIU 

7.13 





a 






23V79 

Internal 

CIU 

7.13 





a 






VS-TC a 

TCB1 

7.13 

■ 

a 

a 

a 


a 

a 




VS-TCl a 

TCB3 

7.13 

■ 

a 

a 

a 


a 

a 

a 



VS- 

Inboard 

7.13 

■ 

a 

a 

a 


a 

a 

a 



6550 a 

TCB 












PM141-VS a 

LCO 

7.13 










a 

50V76 

VS5000 

TC IOC 

7.18.78 

■ 

a 

a 

a 


a 

a 

a 



50V56 

VS5000 

ILC 

7.18.78 









a 



a These devices may be connected to the following Input/Output Controllers 
(IOCs): 22V27, 22V47, 22V67, 23V67, 23V97A, 25V27, 25V67, 25V97, 28V01 
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Note: In addition to the hardware shown in Table 1-1, appropriate 
communications lines and data communications equipment (for example, 
modems and autodialers) are required for the type of transport(s) used 
(both on the local and remote system). 




Software 

The following software components are necessary to support the WSN VS 
NETCORE, Release 8.32.03, software: 

• VS Operating System 

• WSN VS Transport(s) 

• WSN VS Service(s) 

These components are described in the sections that follow. 

VS Operating System Software 

See Table 1-2 for the specific release(s) supported by your system. VS 
Operating System, Release 7.13, is the minimum supported by WSN VS 
NETCORE, Release 8.32.03. 


Table 1-2. VS Model/Operating System 
Software Matrix 


VS Model 

Operating System Release 

7.13 

7.18.78 

5 

■ 


6 

■ 


15 

■ 


25 

■ 


45 

■ 


65 

■ 


85 

■ 


90 

■ 


100 

■ 


7110 

■ 


7120 

■ 


7150 

■ 


300/7310 

■ 


5000 Series 


■ 
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WSN VS Transports and Services 


At least one transport is required to provide a connection to the 
network# and one or more services to provide WSN function. Transports 
and services are ordered separately. See Table 1-3 and Table 1-4 for 
a list of available packages. 


Table 1-3. WSN VS Transport Software 


WSN VS 

Transports 

Recommended 

Minimum 

Release 

Comments 

Point-to-Point (Sync) 
Point-to-Point (Async) 

3.00.01 

3.00.01 

Release 3.02.00 (for both 

Sync and Async) is required 
for VS 5000 Series. 

MLTC Point-to-Point (Sync) 
MLTC Point-to-Point (Async) 

1.00.02 

1.00.02 

Release 3.00.00 or later 
(for both Sync and Async) is 
required for line group and 
Hayes modem support (Async 
only). 

Multipoint Primary 
Multipoint Secondary 

3.00.01 

3.00.01 

Release 3.02.00 (for both 
Primary and Secondary) is 
required for VS 5000 Series. 

Wang Band (External) 

Wang Band (Internal) 

2.08.00 

1.00.02 


X.25 (all types) 

3.40.00 

Release 3.40.30 is required 
for VS 5000 Series. 

Local Communications 
Transport 

3.00.00 


Information Distribution 
System (IDS): 

SNA 

BSC 

2.50.00 

2.50.00 


IEEE 802.3 

1.01.01 

Release 1.02.00 is required 
for VS 5000 Series. 
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Table 1-4. WSN VS Services Software 


WSN VS 

Services 

Recommended 

Minimum 

Release 

Comments 

File Transfer 

Service 

9.06.11 


VS Terminal 

Emulation (VSTE) 

7.15.08 


Virtual Terminal 
Interface (VTI) 

7.11.00 

Requires VS Terminal Emulation. 

X.25 General Access 
Interface (GAI) 

1.02.15 

Requires an X.25 transport. 

X.3 PAD Emulation 
Interface 

1.03.29 

Requires an X.25 transport and 
X.25 GAI. 

Network Application 
Interface (NAI) 

3.06.06 

For writing CNS applications. 

Package Distribution 
Services (PDS) 

3.05.00 

Recommended release is 

3.06 or minimum release 
plus File Transfer, Release 
9.06.11. 


Note: Wang VS OFFICE, Release 2.00, is required if WSNAPPS is used to 
update application records in the WSN Directory. 
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CHAPTER 2 

ENHANCEMENTS AND CORRECTED PROBLEMS 




OVERVIEW 

This chapter describes the key enhancements for Release 8.32.03 of WSN 
VS NETCORE. It also describes problems discovered in previous WSN VS 
NETCORE releases that have been corrected in Release 8.32.03. 


RELEASE ENHANCEMENTS 

The following sections describe enhancements for WSN VS NETCORE, 
Release 8.32.03. 

/-s 

WSNEDIT Support for the MLTC 

The Multi-Line Telecommunications Controller (MLTC) is a new VS TC 
input/output controller (IOC) that supports point-to-point 
communications between VS systems and between VS and PC systems 
(see Table 1-1 for a list of specific models). The MLTC supports up 
to 16 lines. In previous WSN VS NETCORE releases, each line on the 
MLTC had to be configured as a separate data link processor (DLP), 
requiring from 1 to 16 device numbers to serve as control paths (one 
per line). 

Release 8.32.03, in conjunction with MLTC Point-to-Point transport. 
Release 3.00, provides support for "line groups.” This capability 
enables a group of lines on an MLTC to be assigned to a single 
transport, and requires only a single control path for the line 
group. A line group may consist of as few as two lines or as many as 
16. This enhancement simplifies configuration and reduces the amount 
of device numbers required for control paths to support point-to-point 
communications over an MLTC. 
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IEEE 802.3 Transport Support 


Release 8.32.03 expands 802.3 support to include the PC 200/300 
Series, IBM PC AT/XT, and compatible PC systems connected to a VS. 

This capability allows these systems to function as intelligent 
workstations with access to enhanced file and print services on the 
VS. (VS and PC integration requires VS IWSCORE.) 

X.25 Transport Support 

Session Manager includes support for X.25 subaddresses. Subaddresses 
permit a DTE address for a system to be expanded to include an address 
for a particular application on that system. Release 1.03.00 of WSN 
VS X.25 GAI must be used in conjunction with Release 8.32.03 to 
support X.25 subaddressing if GAI applications are being run. 

Configuration Support for Asynchronous Transports 

Previously, when configuring asynchronous communications between VS 
and PC systems, the WSNEDIT utility permanently set the number of stop 
bits on the VS to receive one and send two. 

Changes to WSNEDIT in Release 8.32.03 enable you to set the number of 
stop bits as 1, 1,5, or 2. By selecting the appropriate number of 
stop bits, you can use asynchronous communications more efficiently as 
well as configure for correction of poor line conditions and modem 
errors. 

WSN Configuration Reporter 

WSNPRT is a new configuration reporter utility, which can generate six 
different reports based upon information in the WSNEDIT configuration 
file. These reports enable you to print a copy of your system’s 
local-view configuration, thus providing an accurate record to consult 
when making adjustments to routing-, services-, and transport-related 
aspects of your system's network configuration. The reports and the 
information that they contain are summarized as follows: 

Network Routing -- Lists areas and systems to which paths have been 
defined. Includes next-hop systems, network addresses. Path costs. 
Base costs, and other related parameters. 

Service Summary -- Lists all systems and the services defined for 
each system. Includes CNS, File Transfer Service (CNS and non-CNS), 
Store and Forward, VSTE (logon), and the parameters associated with 
each. 

Transport Addresses — Lists the transports and the systems 
configured on each transport. 
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Device Addresses -- Lists the transports, their IDs, type, DLP 
address, associated line speeds, and the devices assigned to that 
DLP. 

Transport Details -- Lists the transports, their name, ID, CNS 
parameters, DLP address, type, and device numbers. Includes 
additional information specific to transport type (for example, 
Point-to-Point transports include dialing parameters). 

Service Windows -- Lists the configuration of each service window on 
the system. Includes retries, time between retries. Immediate 
Priority Postponement time, and so forth. 

Increased Attached Application Support 

Release 8.32.03 increases the number of attached applications CHS 
supports from 128 to 249. (Refer to the "System Configuration" 
section in Chapter 3 for restrictions.) 

Decreased Operator Intervention in Information Distribution System 
Environments 

With previous releases of WSN VS NETCORE, the deactivation of an 
Information Distribution System (IDS) CICS Region on the IBM host 
system caused the VS to deactivate its IDS SNA links. Subsequent 
reactivation of the IDS CICS Region required network operators to 
manually reenable the link on the VS system. 

Release 8.32.03 is enhanced so that the deactivation and subsequent 
reactivation of an IDS CICS Region requires no manual intervention on 
the VS in order to restore link connectivity between the VS and the 
IBM host. 


CNS Information Distribution System SNA Performance Improvement 

Release 8.32.03 contains enhancements affecting CNS/Information 
Distribution System (IDS) protocols that minimize VS-to-DLP 
input/output and improve data throughput, thus increasing 
communications performance in IDS environments. Dependencies for 
gaining this performance improvement include VS SNA Standard 
Components, Release 2.60.20, and VS IDS Standard Components, 

Release 2.5. 

WSNEDIT Configuration Find Function 

A "Find" function has been added to WSNEDIT that performs a search 
operation to simplify the process of configuring various network 
components such as systems, areas, transports, etc. In large 
networks, these components typically generate long lists, comprised of 
several screens. As an alternative to scrolling through these lists 
to locate a particular component, you can use the Find function (PF6) 
to go directly to the component that you have identified. 


Enhancements and Corrected Problems 2-3 



Enhanced CNS Trace Facility 


The new CNS manager (CNSMGR) utility, which replaces WSNMON, contains 
an enhancement that enables you to specify the size of the CNSLOG file 
that is used by the CNS Trace diagnostic utility. (Previously, the 
file size was restricted to 200 records.) In addition, with CNSMGR, 
activated trace points remain activated even when CNS is restarted so 
that you do not need to reenter these each time WSNSTOP and WSNSTART 
are run. 

Connection Manager 

Connection Manager provides connection services for intelligent 
workstation (IWS) systems on a local area network (LAN) that act as 
independent processors using the VS for resource sharing. The 
Connection Manager validates the IWS user ID and password with the VS 
userlist and invokes the Intelligent Workstation Server (IWSS). The 
IWSS is a component within the VS IWSCORE product. 

WSN Applications (WSNAPPS) Utility 

WSNAPPS is a new utility that enables you to manage certain 
user-written network applications for inclusion in the WSN directory. 
Applications that are added to the WSN directory can be automatically 
started on the local VS by remote users or applications that have 
access to the WSN network. 

Currently, the WSNAPPS utility is only recommended for managing 
user-written. Network Application Interface (NAI)-based applications. 
In addition, the WSNAPPS utility includes functions that are reserved 
for Wang analyst use only. 

Merge Facility for Starter Kit 

A merge facility has been added to the import of a starter kit. This 
facility allows for the contents of the starter kit to 

• Overwrite the existing directory. 

• Merge only new definitions into an existing directory. 

• Merge new definitions and replace existing definitions. 

VADIC Automatic Call Unit Dialer Addresses 

The range of VADIC Automatic Call Unit (ACU) Dialer Addresses have 
been extended to 0 through 7 in order to accommodate operation with 
the VADIC full-duplex modem. 
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Changes to LOGTSK 


LOGTSK is the background task that is responsible for reading and 
writing the current day’s log file. Release 8.32.03 contains the 
following enhancements to improve LOGTSK performance: 

• Capability to run independently of CNS, thus supporting logging 
functions on systems using non-CNS communications/ such as 
Transmission Control Protocol/Internet Protocol (TCP/IP). 

• Automatic submission of the Distributed Management Facility (DMF) 
Logger Consolidation program (LOGCOM) when DMF is present, the 
CONSOLIDATION parameter for LOGCNTRL is ENABLED, and any messages 
are logged that DMF has designated for immediate or periodic 
consolidation to a remote node. 

• Management of the TSLOG file size. LOGTSK now ensures that the 
TSLOG file does not exceed 13 extents. Prior to reaching this 
maximum, LOGTSK performs reorganizing operations to reduce the 
number of extents needed to store log records. 

• Managing TSLOG file record counts. LOGTSK now ensures that the 
TSLOG file does not exceed the maximum record count that you set 
through the LOGCNTRL utility. When a maximum record count is 
reached, LOGTSK sends a message to the daily log file indicating 
that further messages will be lost until sufficient space in TSLOG 
is available. 

For information on what to do when the TSLOG is full, refer to the 
"Logger Considerations" section in Chapter 3. 

Enhanced Multihop Routing 

PC systems that are using Wang Professional Computer 802.3 Integrated 
Services to connect with VS systems over an 802.3 local area network 
(LAN) can take advantage of enhanced multihop routing capabilities. 
These capabilities minimize routing configuration on the PC and serve 
to identify appropriate gateway VS systems for routing multihop 
traffic. PC systems include Wang Professional Computer 200/300 
Series, IBM PC AT/XT, and compatible systems. (For more information 
about this feature, refer to the "WSNEDIT: Transports/Services/Routing" 
section in Chapter 3.) 
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CORRECTED PROBLEMS 


The following sections describe problems found in previous WSN VS 
NETCORE releases that have been corrected in Release 8.32.03. 

31 or 32 Nonadjacent Systems 

Previously, when either 31 or 32 nonadjacent systems were selected for 
File Transfer or VSTE Logon, the local system would occasionally fail 
on initial program load (IPL). 

This problem has been eliminated in Release 8.32.03. 

Deleting Systems From Store and Forward Windows 

When Store and Forward systems are deleted from the directory without 
first being deleted from the WSN service window, a discrepancy occurs 
between the communications configuration file and the directory file, 
which results in the failure of subsequent Store and Forward 
operations. 

To keep this discrepancy from happening, a message is displayed when 
you attempt to delete a service window, which notifies you to delete 
any destination systems first from the associated service window. 

Configuring Multipoint Transports 

WSNEDIT no longer allows the incorrect configuration of a multipoint 
transport with only secondary systems. WSNEDIT now prompts for the 
designation of the primary system when the primary system is missing 
from the Multipoint System Designation screen. 

Exiting From CNFGAID 

Previously, CNFGAID allowed you to select a program that was not 
installed on your system. When a noninstalled program was selected, 
CNFGAID would not allow you to exit from the screen. 

The CNFGAID menu now displays selections only for programs that are 
currently installed on the system. 

WSNSTOP Functions 

WSNSTOP now runs a procedure that instructs CNS to close all active 
sessions with PC workstations. This corrects the problem relating to 
PC systems and intelligent workstations (IWSs) when CNS is terminated 
without first terminating all of their associated sessions. 

WSNSTOP also terminates Wang OFFICE mail tasks (if executing) prior to 
stopping networking tasks. 
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CNS Recovery 

In previous WSN VS NETCORE releases, CNS would occasionally not 
recover properly when it received an abnormal link termination from a 
DLP configured for WSN. This problem is corrected in Release 8.32.03. 

Remote Interprocess Task Recovery 

In the event of a CNS task failure or connection timeout, 

@RMTIPC@--the remote interprocess task for the VS Operating 
System—can now recover. Should a CNS task failure occur, @RMTIPC@ 
reinitializes and then reattaches to CNS when CNS activity resumes. 
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PHADTFR 1 

SPECIAL CONSIDERAtlONS 


INTRODUCTION 

This chapter provides a listing of the considerations, restrictions, 
and conditions that apply to the operation and administration of WSN 
VS NETCORE, Release 8.32.03 software. 

CONSIDERATIONS AND RESTRICTIONS 

This section describes considerations and restrictions for the 
configuration and operation of systems running WSN software. It is 
provided here as a reference for modifying certain system/network 
parameters that are normally affected by adjustments to routing-, 
services-, or other network-related aspects of a system’s 
configuration. 


System Configuration 

The following considerations and restrictions apply to VS system 

configuration: 

• Wang VS NETCORE requires four background tasks ($CNSTSK$, 

$LOGTSK$, 0RATGATE 1 , and @RMTIPC@) and two dedicated system tasks 
(@FTMTSK@ and @SESMGR@); @RATTSK@ comes up as a background task 
only if VSTE is installed. Additional background tasks are 
required for Wang OFFICE/Store and Forward ($WOAMGR$, $SFMGR$, 
$DSMGR$, and $SYNDIR$). If VS IWSCORE using an 802.3 link is 
installed at a later date, two additional background tasks are 
required for Netbios Datagram Server ($NDS$) and Connection 
Manager 2 ($CNXMGR$). $NDS$ is submitted by WSNSTART if it has 
been installed by the IWSCORE install. 

1 Only necessary if non-CNS remote logons are allowed. 

Connection Manager is not required unless VS IWSCORE is installed. 

If you are not using VS IWSCORE, you can remove Connection Manager by 
deleting the file ($CNXMGR$) from library @SYSTEM@ on the IPL 
volume. If WSN VS NETCORE is reinstalled. Connection Manager is 
automatically replaced by the install procedure. 
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• Release 8.32.03 does not support $CNSTSK$ running as a foreground 
program. 

• CNS MANAGER (CNSMGR), WSNEDIT, $CNXMGR$, and @EVTINQ@ must be run 
from user IDs with modifiable data areas of at least 1024K. 
$CNSTSK$ must be run from background task initiators that have at 
least 2048K of modifiable data area available. Under the 
following conditions CNS requires at least 3072K of modifiable 
data area (Segment 2): 

Systems that are processing a large amount of traffic such as 
the Network Control Center of a very large network. 

Systems that have between 100 and 150 simultaneously active CNS 
sessions. (For 150 to 256 active sessions, 4096K is required.) 

Systems that have more than 100 attached CNS applications. 

Systems that have over 200 adjacent system/transport pairs 
configured in their WSNEDIT file. For instance, 200 adjacent 
systems on one transport constitute 200 adjacent 
system/transport pairs; 100 systems on one primary transport 
and on one backup transport also constitute 200 adjacent 
system/transport pairs. 


Note: Modifiable data area requirements have increased in WSN VS 
NETCORE, Release 8.32.03. If you are upgrading from an earlier 
release of WSN VS NETCORE , you may need to increase the amount of 
modifiable data area that was previously configured to support 
Release 8.32.03. 


Modifiable data areas are configured when background task 
initiators are created from Non-Interactive Tasks in Operator Mode 
(refer to the VS System Operator's Guide for instructions). 

If you want to create background task initiators having varying 
sizes of modifiable data area and ensure that a particular network 
task such as CNS is submitted to the appropriate initiator, you 
can do so by the Job Class associated with the initiator. For 
example, you can create most initiators having a modifiable data 
area size of 1024K and assign a procedure class of A to these 
initiators. Then you can create another initiator (for CNS) 
having a modifiable data area of 2048K and assign it a procedure 
class of B (or any other unused letter designation that you want 
to assign). 

In the following example, a procedure class of "B" is used to 
designate the CNS initiator. This letter, and the letter that is 
used to submit CNS by the WSNSTART procedure, must match. 

(WSNSTART is the procedure that you run to submit network 
background tasks.) 
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To ensure that CNS is submitted to the "B" initiator by WSNSTART 
while the other network tasks are submitted to the default A class 
of initiators, the WSNSTART procedure in @SYSTEM@ on the IPL 
volume can be modified as follows ( underlining represents 
modification to the standard WSNSTART): 


Procedure WSNSTART version 01.00.19 - Submit Network background 
jobs. 

[ (c) Copr. Wang Laboratories, Inc. 1986 ] 


declare &PR0GV0L 

declare &PR0GLIB 

declare &CHECK, &PFKEY 

extract &PR0GV0L=progvol, 


string(6) 
string(8) 
integer 
PROGLIB=proglib 


submit @RMTIPC@ as @RMTIPC@ 


[ Remote IPC ] 


if not exists file $WSNEND in &PR0GLIB on &PR0GV0L goto NOWSN 
submit $CNSTSK$ as $CNSTSK$, CLASS=B [ CNS itself ] 
submit $L0GTSK$ as $L0GTSK$ [ CNS ( & DMF ) Logger ] 

if not exists file CHECKNET in &PR0GLIB on &PROGVOL goto L0GC0M 


CHECKNET: 

run CHECKNET in &PR0GLIB on &PROGVOL [check if CNS is up ] 


LOGCOM: 

submit $LOGCOM$ as $L0GC0M$ [ For DMF, if installed. ] 


NOWSN: 

if not exists file $CNXMGR$ in &PR0GLIB on &PROGVOL goto NOCNMGR 
submit $CNXMGR$ as $CNXMGR$ [ Connection Manager ] 


NOCNMGR: 

if not exists file RLGSTART in &PR0GLIB on &PROGVOL goto NORLG 
run RLGSTART in &PR0GLIB on &PR0GV0L 

[ RLGSTART submits 0RATTSK0 ] 


NORLG: 

if not exists file $MAILEND in &PR0GLIB on &PR0GV0L goto NOMAIL 


[ Wang Office Activity Mgr. ] 
[ Store & Forward ] 

[ WO Traveling User Facility] 
[ Directory Queries (OFM,PC)] 
submit $SYNDIR$ as $SYNDIR$ [ In case of earlier crash. ] 


submit $W0AMGR$ as $W0AMGR$ 
submit $SFMGR$ as $SFMGR$ 
submit $TUSTRT$ as $TUSTRT$ 
submit $DSMGR$ as $DSMGR$ 


NOMAIL: 

if not exists file $DISEND in &PR0GLIB on &PR0GV0L goto NODIS 
submit $DIS0SI$ as $DIS0SI$ [ Inbound gateway ] 
submit $DIS0S0$ as $DISOSO$ [ Outbound gateway ] 
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Procedure WSNSTART (continued) 


NODIS: 

if not exists file $SUBPRF$ in &PROGLIB on &PROGVOL goto NOPROF 
run $SUBPRF$ [ Submit all tasks] 

NOPROF: 

if exists file OIDBM in &PROGLIB on &PROGVOL 

submit OIDBM as $OIDBM, CLASS=0 [ Office Indexer task ] 

if exists file $NDS$ in &PROGLIB on &PROGVOL 

submit $NDS$ as $NDS$ [NETBIOS DATAGRAM SERVER] 


return 


If CNS abnormally terminates, it will resubmit itself (using the 
procedure $CNSTSK$ in @SYSTEM@) in order to make sure that the 
network becomes operational again as soon as possible. To ensure 
that CNS resubmits itself to the appropriate initiator, the 
$CNSTSK$ procedure in @SYSTEM@ on the IPL volume must be modified 
as follows. (A procedure class of "B" is again used in this 
example. You must use the same letter that you used to create the 
initiator and submit CNS by WSNSTART.) ( Underlining represents 
modifications to the standard procedure .) 


PROCEDURE: 

DECLARE &RCODE INTEGER 
SET PRNTMODE=H 
SET JOBCLASS=B 


CNS: 

RUN CNS IN @SYSCOM@ ON SYSTEM 

ENTER NOTCLOSE 

ENTER NOTCLOSE 

ENTER NOTCLOSE 

ASSIGN &RCODE = CNS 

RETURN CODE = &RCODE 

To ensure that CNS is submitted to the correct background 
initiator when started from CNSMGR, you must modify the CNSMGR 
procedure in @SYSTEM@ in a similar manner. 


Note: If WSN VS NETCORE, Release Q.32.03, is reinstalled, the 
modified WSNSTART, $CNSTSK$, and CNSMGR procedures in QSYSTEMQ on 
the IPL volume are replaced with the standard procedures, 
eliminating the changes made, For this reason, you are advised to 
keep copies of these modified procedures on your system so that 
they can be easily restored. 
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• If network data files are put on a multivolume set/ it is 
important to ensure that all volumes are permanently mounted. If 
the Directory file volume in a set is dismounted, many network 
applications can become suspended while waiting for the volume. 

If the CNS logger is assigned to a multivolume set, ensure that 
there is adequate space on the volumes in the set for the daily 
log files. Operational delay in responding to a mount may result 
in loss of log records. 

• For systems with large numbers of TC devices (DLPs) configured in 
GENEDIT, it is important to increase the Maximum Open Files value 
found under Task Options in GENEDIT since each TC device in use by 
the CNS task for sessions is considered an open file by the 
Operating System. (The default value is 25.) Make sure that the 
Maximum Open Files value is at least 10 more than the total TC 
devices configured on DLPs used by transports that have CNS 
systems configured on them in the WSNEDIT file. If an inadequate 
number of Open Files is configured, CNS may abort and produce no 
dump file. 

• The maximum number of applications that can attach to CNS is 
calculated as follows: 

249 - (# of transports enabled) 


WSN Operations 

The following considerations and restrictions apply to WSN VS system 
operation: 

• All VS computers communicating via the 802.3 link must be upgraded 
to WSN VS NETCORE, Release 8.32.03 and WSN VS 802.3 Transport, 
Release 1.01.01 or later. 

• Operation of WSN VS NETCORE requires certain security privileges, 
which you can set up through either one of the following ways: 

Assign a user ID for starting the network with full security 
and file access privileges, and a subtask quota of 255. This 
is done by running the VS SECURITY program and assigning these 
rights to the selected user ID. 

or 

Assign full security and file access privileges to the network 
programs that WSNSTART submits. Run the VS SECURITY program to 
assign rights to these programs. In addition, because a 
subtask quota can not be assigned to a program but only to a 
user ID, make sure that the user ID for starting the Connection 
Manager (@CNXMGR@) is assigned a subtask quota of 255. 
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Use the following procedure when it is necessary to halt network 

operations for a period of time: 

1) Notify remote users that the network is being halted. 

2) If DMF is installed, run DMFSTOP. 

3) Run WSNSTOP to terminate CNS and any network applications that 
are currently running. 

4) If the system requires an IPL, you should wait about five 
minutes for any remaining background tasks to terminate. 
(Before you IPL, you should check to see if all tasks have 
stopped by using the Operator Console, Control Non-Interactive 
Tasks function and by checking the procedure queue.) 

The following procedure should be used to restart network 

operations: 

1) If an IPL was just completed on the system, it is recommended 
that you run WSNREORG to reorganize and backup the WSN 
directory file. 

2) Run WSNSTART to restart $CNSTSK$, $LOGTSK$, and other 
background CNS applications (including Wang OFFICE). 

3) If DMF is installed, run DMFSTART. 


i r*\ 




The output file from WSNEDIT is the COMMFILE named during the IPL 
process. If you edit and replace the active file while the 
network is running, some information is read immediately, some 
becomes effective when $CNSTSK$ is stopped and restarted, and some 
takes effect only after the next IPL. New systems in other areas 
and changed area distribution points, for example, will take 
effect immediately 1 . Changed routing will take effect when 
WSNSTOP and WSNSTART are used to restart $CNSTSK$. Transport 
changes, new transport addresses for systems, or changes to 
service parameters will not take effect until the next IPL. 

Operation of the WSN software requires that the volume containing 
the directory file be mounted. 


Requires that the Store and Forward Manager (@SFMGR@) and the Wang 
OFFICE Manager (@WOAMGR@) be halted and then restarted. Refer to the 
VS OFFICE Administrator's Guide for details. 
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• With Wang OFFICE installed, the directory is permanently open by 
background tasks that frequently update the file. The directory 
is, therefore, subject to failures when the system fails during an 
update, also, it may be difficult to maintain a valid backup 
because of its frequent usage. Arranging to run WSNREORG after 
every IPL prior to WSNSTART helps to alleviate both problems. The 
file is immediately reorganized in case an update was in progress 
before the IPL, and a backup copy is made available. That copy 
cannot be opened by background tasks, and is, therefore, 
accessible to customary backup procedure. 

If WSNREORG does not run to completion for some reason, the 
directory may be damaged. The message presented by WSNREORG is 

Rename of backup copy was unsuccessful. 

File ^Directory file name) in WSNREORG on (Directory volume) 
Return code from rename was 52. 

Press ENTER to acknowledge. 

Restore the backup copy ONEPRIOR in library WSNREORG to the 
directory file library and rename ONEPRIOR to the name of the 
directory. 

• INSTALL, WSNEDIT, and WSNDIRM all fail when an IPL is performed on 
the VS with the "one workstation and one disk" IPL option. This 
failure occurs because the extracted WangNet system name on which 
they depend is blank. 

• If TCB1 or TCB3 DLP dumps occur and the halt code displayed by the 
DUMPSCAN program shows the halt code to be "001B," it is possible 
that the RS-232 cable between the TCB1 or TCB3 and modem has been 
disconnected or is loose. Correct by reconnecting or tightening 
the connection. 

• Although WSN VS NETCORE, Release 8.32.03, can allow larger 
configurations, for performance-related reasons, only 
configurations that conform to the following restrictions are 
supported: 

Maximum hop count - 6 

- Maximum number of paths to any one destination system = 3 

- Maximum number of transports between adjacent systems = 2 

Care should be taken when creating each VS system's local-view 
file with WSNEDIT to be sure that the resulting configuration 
meets the above restrictions. 
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• If the system being configured has more than three adjacent 
systems in another area, only three of those systems can be 
configured as possible next hops to that area. By default, the 
first three in alphabetical order will be given Path costs by 
WSNEDIT. Deleting the Path cost from one of the first three does 
not cause automatic addition of the fourth adjacent system as a 
next-hop system to the area. To configure another adjacent system 
as a next hop to that area, delete one of the three defaults and 
assign a Path cost for the desired system. 

• The following are the limits that WSN VS NETCORE, Release 8.32.03, 
supports: 

150 areas in a network 
300 systems per area 

2000 total systems in the network (800 total systems is the 
generally recommended maximum for acceptable performance) 

50 transports per system (29 transports is the maximum that can 
be enabled concurrently) 

512 total systems for File Transfer Service using CNS 

512 adjacent systems, which can be CNS 1 , non-CNS, or a 
combination of both. 

• When utilizing a communications file that was created by WSNEDIT 
on a system other than the local system or by a previous version 
of WSNEDIT, that communications file should be input to WSNEDIT 
and then replaced when WSNEDIT is exited. This procedure ensures 
that the correct local system name and features are added to the 
communications file. Perform this procedure by running WSNEDIT, 
selecting Manage Transports and entering the name of the 
communications file. Exit this function and name the 
communications file with the same name as the input file. Press 
PF3 to replace the file. 

• When installing a new version of a transport that has default 
parameters under the control of a "CERTIFICATION" file (such as, 
802.3 or X.25), and the certification file has changed in the new 
release, the transport must be deleted and then recreated using 
WSNEDIT in order for any changes in the default parameters to take 
effect. (Refer to the particular transport customer software 
release notice to determine if this is a requirement.) 




,0 


1 This requires three megabytes of Modifiable Data Area Size 

(segment 2 memory) or greater on the VS. For CNS, a system is 
defined as a system-transport pair (for example, a single 
system defined on two transports counts as two systems). 
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WSNEDIT: Directory 


The following considerations and restrictions apply to WSNEDIT 

network-view configuration: 

• The System WangNet ID that was defined in the GENEDIT file used at 
the last IPL is the network name of the VS. This name must be 
defined in the WSN directory before network configuration can 
proceed. Also, if the System WangNet ID defined in GENEDIT does 
not match the local system name in the directory file, a 
correction is required before network configuration can proceed. 

If the network name in the WSN directory is incorrect, you must 
correct it by running WSNDIRM. (WSNDIRM can be run from CNFGAID, 
or it is called automatically by WSNEDIT if the problem is 
discovered during configuration.) 

If the System WangNet ID in the GENEDIT file is incorrect, you 
must IPL the system using a corrected GENEDIT file. 

• The Administrative system (also called the Area Control Center 
(ACC) for DMF), must be configured for each area defined in 
WSNEDIT if Wang OFFICE, Directory Synchronization, DMF 
notification, or log consolidation is to occur within that area. 

A Network Center (called the Network Control Center (NCC) for DMF) 
must also be identified for the network and it must be the 
Administrative system for its area. These systems must be 
configured as CNS systems. 

• Every system in the network, including the local VS, must be 
configured as either a CNS or a non-CNS system. Every system with 
CNS installed must also be configured to specify whether it uses 
CNS for File Transfer and whether it has Store and Forward 
installed. These options are defined by running WSNEDIT, 
selecting MANAGE AREAS, and then selecting the desired area and 
system record to create/modify. You describe your configuration 
by responding to the following queries: 

Has WSN with CNS been installed? YES/NO 

Shall File Transfer use WSN with CNS? YES/NO 
Has Store & Forward been installed? YES/NO 

The rules for responding to these queries are 

If WSN with CNS is not installed, all answers must be NO. OIS, 
Alliance®, and 2200 do not support CNS. VS and Wang PC/APC 
systems may have CNS installed. PC 200/300 Series, IBM PC 
AT/XT, and compatible systems do not support CNS until Wang 
Professional Computer 802.3 Integrated Services is available 
and running on these systems. IDS systems must have CNS. 
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If WSN with CNS is installed 


— File Transfer is YES for any CNS VS, unless you do not want 
File Transfer to use CNS (that is, to multihop). YES is 
recommended for CNS VS systems since session recovery is 
enhanced with CNS; YES is required for IDS systems. 

— File Transfer must be NO on a Wang PC/APC, even though CNS 
is installed to support PC Wang OFFICE, unless the Wang 
Professional Computer WSN Basic Support Services (BSS), 

Release 3.0, is installed on the PC/APC. 

— Store and Forward is YES on any system with Package 
Distribution Services (PDS) installed. 

• A Primary Distribution Point must be configured in each Area for 
PDS to operate correctly. The system defined as the distribution 
point must be configured as a CNS system with Store and Forward 
installed (that is. Package Distribution Services). 

• For PC Wang OFFICE to work correctly, PC LIO networks must reside 
in a separate area from VS systems. Single remote PC systems may 
belong to an area with VS systems as long as a VS is the area 
Administration system and the Primary Distribution Point for PDS 
Store and Forward. 

• The program DIRPTR, which is used to set the location of the WSN 

Directory, should not be run to change the current directory while r\ 

communications are enabled or any network utility is being run 

(such as WSNEDIT). This creates discrepancies between the 
Directory and the WSNEDIT configuration file, which produce 
unpredictable results. 

WSNEDIT: Transports/Services/Routing 

The following considerations and restrictions apply to WSNEDIT 

local-view configuration; 

• WSN VS Point-to-Point switched transports operate best with 
autodialers. If manual dialing is configured, $CNSTSK$ will try 
to use the transport, but there will be no notification of a 
pending required manual call. If necessary, a manual-dial line 
can be configured as point-to-point half duplex, which would force 
it to stay connected for WSN use once it is dialed. 

Note: Manual dialing is not supported on MLTC-configured 
transports. 
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• For call group support, multiple Point-to-Point switched 
transports can each be configured with a group of destination 
systems. With rotary hunt equipment, any configured system can 
dial in and use any of those transports. Thus, all 50 transports 
(the maximum number allowed) can be Point-to-Point switched, 
although only 29 can be enabled for CNS at any given time. 

• When using WSNEDIT to configure Point-to-Point switched transports 
with autocall units, make sure that the value for "Dial Retry 
Count" multiplied by "Dial Delay Time" is less than 2 minutes. 
Failure to configure these parameters correctly will result in 
$CNSTSK$ timing out before the DLP does, and may produce WSN log 
messages that appear to be out of sequence. Also, the CNS task 
may take long periods to cancel when WSNSTOP is run or $CNSTSK$ is 
cancelled through CNSMGR. 

Recommended values for Point-to-Point switched links that are part 
of a backup group used by CNS for alternate routing to a 
destination system are 

Disconnect Timer — 10 seconds 
Dial retry -- 1 second 
Dial delay -- 10 seconds 

These values should be kept low so that when a line outage occurs, 
the link level recovery is exhausted in a relatively short period 
and CNS can quickly switch to an available backup link. 

• When configuring the dial sequence for a Hayes modem/autodialer, 
the "W" command (wait for dial tone) may be entered. If this 
sequence is subsequently displayed, a colon (:) appears in place 
of the "W." Both characters represent the same modem command. 

• When configuring a Multi-Line Telecommunications Controller 

(MLTC), for WSN point-to-point communications, the following 
configuration guidelines should be observed: 

Using VS GENEDIT, configure the MLTC as a single DLP for each 
line group (i.e., two or more lines sharing the same transport) 
so that only one device number per line group is needed for the 
control path. 


Vote: Line group support for MLTCs is not available until MLTC 
Point-to-Point Transport, Release 3.00. Prior to using Release 
3.00, the MLTC must be configured as multiple DLPs, one per line. 


Using WSNEDIT, assign a transport to each DLP address. 
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- Using WSNEDIT, associate the transport with the physical line(s) 
using the Define Line Group Definition screen. 

• On congested systems (that is, systems with extensive 
communications demands), autostarted applications such as DIRSYNC 
or DIAG1 may not start within the time allowed by the defaulted 
value of the transport inactivity timer. When configuring 
transports in WSNEDIT that are used for establishing sessions to 
these applications, it may be necessary to increase the values 
displayed as defaults for "Inactivity Timeout" and "Reactivation 
Timer" to ensure that CNSMGR diagnostics and DIRSYNC operate 
correctly. 

• When defining a DLP in GENEDIT, the DLP must be defined on the 
lowest device number that you intend to assign to that DLP. If 
any cluster device has a lower device number than the DLP address, 
the microcode will not load and initialize properly. 

• When defining your local communications configuration in WSNEDIT, 
any system with WSN VS NETCORE installed can be added to WSN VS 
File Transfer and Logon Services whether or not the system is 
connected by a transport. However, if a system that is connected 
by one or more transports to your local system is subsequently 
deleted from all transports, the system is also deleted from any 
services that are configured. If that system is not on a 
transport but can be reached through an intermediate system, you 
can restore it by adding the system to the services after it has 
been deleted from all transports. 

• If two paths defined for a destination have the same Path cost, 
the first path defined (that is, the path listed first on the 
Transport List menu) is selected. 

• When configuring a network in which the path between source and 
destination systems requires multihopping, some transport 
combinations may cause the software to fail. This happens when 
the path is required to use the same switched transport twice, as 
shown in the following example: 


VS A 

Switched Link 

VS B 

No Connection 4 

VS C 

P-P TCB 

P-P TCB 

P-P TCB 




a The VS B TCB cannot be used to communicate with VS C since it is 
already being used to communicate with VS A. 
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For example, if a route is defined from VS A to VS C through 
intermediate VS B, and the intermediate VS system uses the same 
switched transport (that is, the same DLP, modem, and line) to 
reach both the VS A and VS C, a session from VS A to VS C or vice 
versa cannot be established on behalf of any CNS application. 

Both the modem and line will already be in use when the 
intermediate system attempts to establish the second leg of the 
path required for the session. Also, if VS A is the Primary 
Distribution Point and VS C the Network Center, directory 
synchronization can never take place since the end-to-end session 
must be from VS A to VS C. 

• Wang Professional Computer 200/300 Series, IBM Personal Computer 
AT/XT, and compatible systems that are connected to a VS over an 
802.3 LAN can use enhanced CNS multihop routing capabilities, 
which require only minimal routing configuration at the PC. 

Using an algorithm applied to the WSNEDIT configuration file, VS 
systems on the 802.3 LAN determine whether they are a gateway or 
end-point system and broadcast this gateway capability on the 
LAN. PC systems with multihopping data traffic choose the VS with 
the lowest Area ID and System ID from the available gateways 
active on the LAN and route multihop traffic through that VS. The 
VS that receives the PC traffic then routes the traffic using CNS 
to the destination system. If another VS has a more direct route 
to the destination system than the one selected, the PC acquires 
this information from returning data messages and uses it to 
select that VS for future routing to the destination system. 

Traffic to systems that are directly connected to the 802.3 LAN 
does not use this routing method but is routed directly from the 
source PC to the destination system. 

• PDS Store and Forward service windows can only be defined for 
Store and Forward systems at this time. In addition, Wang OFFICE 
and Software Manager are the only WSN products that can currently 
take advantage of service window capabilities. 

• An IDS host that is being used as a pass-through system by PDS, 
must be configured as having File Transfer Service installed. 

• The initial transport status "ENABLED/DISABLED,” which is set in 
WSNEDIT on the General Transport Definition screen, applies only 
to CNS use of the transport. Non-CNS use is still under control 
of the Operator Communications Control functions "inhibit/allow" 
(refer to the WSN VS Network Control and Monitoring Guide for 
details). If only non-CNS systems are defined on a transport, set 
the initial status to "DISABLE" when configuring the transport. 
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• WSNEDIT does not allow duplicate DTE addresses to be assigned to 
systems on X.25 data links (transports). If you have several 
systems, such as PCs, that are sharing the same X.25 access line 
via a multiplexor, you can use any one of the following procedures 
to configure these systems in WSNEDIT. 

Use the subaddress portion of the X.25 address to distinguish 
between systems. In this case, the PCs each have the same DTE 
address except for the subaddress portion. Assign a unique 
subaddress value for each system that you are configuring. 

If the PCs are intended to only initiate the connect request 
with a VS, they can each be given a unique, valid, dummy DTE 
address to assign them to the X.25 transport. This causes no 
conflict since the addresses will not be used by the X.25 
network for routing. 

If the PCs are intended to receive calls that are initiated by 
the VS, then assign each PC the same WSN system name (WangNet 
ID), Area ID, and System ID, and configure one of the PCs on 
the X.25 transport with the appropriate DTE address. Since 
only one of the PCs can be active at any time, there should be 
no conflict. 

WSN Logger 

The following considerations and restrictions apply to WSN VS logging 

functions: 

• If Logger data files are put on a multivolume set, ensure that all 
volumes are permanently mounted. If the Logger file volume in a 
set is dismounted. Logger activity is suspended while waiting for 
the volume, resulting in a loss of log records. Furthermore, 
check to be sure that there is adequate space on the volumes in 
the set for the daily log files. Operational delay in responding 
to a volume mount can result in a loss of log records. 

• You can reconfigure logging (initially set during WSN VS NETCORE 
installation) by running the LOGCNTRL program from CNFGAID, and 
selecting a volume for logging. The library @LOG@ is created on 
that volume with a file named "Lyymmdd" (year, month, day) for 
every day the logger is running. Files will build up in that 
library and should be archived or scratched regularly to save disk 
space and to improve the performance of Event Inquiry. LOGCNTRL 
creates the file @LOGCTL@ in 0SYSTEM0 on the system volume. 
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• If logging parameters in LOGCNTRL need to be modified, proceed as 
follows: 

1) Halt all currently active foreground programs that log to the 
logger. 

2) If DMF is present, run the procedure DMFSTOP to halt LOGCOM in 
background. 

3) Run the procedure WSNSTOP to halt CNS and LOGTSK in background. 

4) Run the configuration procedure LOGCNTRL from CNFGAID or from 
DMF (Control Logging) to reset logging parameters. 

5) Run WSNSTART to resubmit to background CNS, LOGTSK, and any 
other installed applications dependent upon CNS. 

• Prior to performing an IPL of the VS system, the procedure DMFSTOP 
must be run to halt LOGCOM in the background if DMF is present, 
and all background and foreground applications that write log 
messages to the logger must be stopped or cancelled. Next, the 
procedure WSNSTOP must be run to halt CNS and LOGTSK in 
background. Since the procedure WSNSTOP will end prior to the 
actual halting of LOGTSK in background (due to a processing 
response time lag from use of an ITMU port to signal cancelling), 
care should be taken to ensure that LOGTSK has actually halted 
before starting the IPL. Failure to do so may cause the 
(post-IPLed) background task LOGTSK to dump with DMS message "File 
Not Closed," as well as cause loss of data in the logfiles open 
during the IPL. This occurs because the partially halted 
(pre-IPLed) LOGTSK (still in procedure queue) still has files 
open, though it may be without an ITMU port. 

• After an unexpected system failure, or after performing an IPL of 
the VS without having first run WSNSTOP as described above, it may 
be necessary to reorganize either one or all of the files listed 
as follows: 

@LOGCTL@ in system library on system volume 
TRLOG in @LOG@ on logger volume 
TSLOG in @LOG@ on logger volume 
Lyymmdd in @LOG@ on logger volume 

To reorganize each file, first rename it and then run COPY to copy 
the file to its original filename with option REORG=YES. 
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• When the send log (TSLOG) file is full (i.e., the 13 extents 
maximum is reached) and logging is halted, perform the following 
operations to reduce the TSLOG file size and continue logging 
operations: 

Rename TSLOG and copy with reorganize back to TSLOG 

Compress the disk pack that TSLOG uses 

Once you reduce the size of the TSLOG file, follow the procedure 
given previously for modifying LOGCNTRL parameters to reset 
CONSOLIDATION = YES. 

• Managing TSLOG file record counts. When a maximum record count is 
reached, LOGTSK sends a message to the daily log file indicating 
that further messages will be lost until sufficient space in TSLOG 
is available. At this point, in order to log new messages, you 
can either increase the number of records allocated to TSLOG or 
delete the existing records. Once space is available in the TSLOG 
file, logging operations automatically resume. To avoid overuse 
of the logger and resultant maximum record count, check to ensure 
that the logger is not being overburdened by unnecessarily large 
numbers of outbound consolidating log messages. Note that local 
alerts in conjunction with DMF will still perform under the above 
conditions. 

• When the daily log file (Lyymmdd) is full (i.e., maximum record 
count is reached), LOGTSK will automatically reduce the size of 
the file Lyymmdd by reorganizing the records. When this fails to 
produce sufficient space for logging to continue, LOGTSK will 
halt, causing any new messages to be lost. When this situation 
occurs, you can try one or more of the following options to 
increase disk space: 

Reorganize the volume 

Delete files 

Increase the maximum number of extents for the volume 

Once space is available for Lyymmdd, logging operations 
automatically resume. 
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Event Inquiry 


The following considerations and restrictions apply to the WSN Event 

Inquiry (EVENTINQ) function: 

• When the WSN VS NETCORE software is installed, the Event Inquiry 
runtime executable module @EVTINQ@ and its associated forms file 
EVTFORMS are moved to library @SYSTEM@ on the system volume, where 
they must reside in order for standalone managers, such as CNSMGR, 
to function properly. The procedure EVENTINQ, which calls 
@EVTINQ@, remains in library @SYSCOM@ on the installation volume. 

A second procedure EVENTINQ is created in @SYSTEM@ on the system 
volume at installation. This procedure calls EVENTINQ in @SYSCOM@ 
and can be moved or copied to any library. 

• Care should always be taken to IPL the VS with the correct date 
and time of day. Failure to do so may cause log records to appear 
out of sequence and to give the appearance of lost records while 
running Event Inquiry. 




• Event Inquiry defaults to display all subsystem messages (assuming 
that they were intended to be logged as Event messages), and thus 
displays some unreadable messages intended to be statistics 
messages. These unreadable messages can be ignored. 

• The Event Inquiry response time can increase when the Respecify 
option (PF9) is pressed. The response time is proportional to the 
sum total of log records present in all the daily log files. Even 
though a logger subsystem may be specified for which there is 
relatively few logged messages, all log records must nevertheless 
still be reread upon entering the Respecify option to be certain 
of this. Response time can be improved by deleting "old" daily 
log files. 


Connection Manager 




The following considerations and restrictions apply to the WSN 

Connection Manager (CNXMGR) function: 

• The user who starts the Connection Manager should be a security 
administrator and allowed to have subtasks. This is accomplished 
by setting the subtasks field in the Security program to a nonzero 
number. (A value of 255 is recommended.) If the subtask quota is 
zero or is met, the Connection Manager is unable to verify user 
IDs or invoke any more tasks. 

• During startup, the Connection Manager automatically attempts to 
start the applications: LST928, LST8208, BSV, and TRMGR. The 
inability to start these applications causes messages to appear in 
the logfile. This is a normal condition. These applications have 
no effect on the operation of WSN VS NETCORE, Release 8.32.03. 
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CNS Manager 


The following considerations and restrictions apply to the WSN CNS 

Manager (CNSMGR) function: 

• CNSMGR contains a hidden function for printing the screen. This 
function is accessed by pressing PF31 while viewing the screen. 

• On the Control/Monitor CNS Transport screen, the "Total Cost" 
value that is displayed is only significant in cases where you are 
monitoring a transport that is limited to communication between 
your system and one other system, such as with point-to-point or 
IDS links. This is due to the Congestion level factor, which is 
derived from the last congestion level received by the link 
driver. In all other cases, you should examine the "Relative 
cost" value, which appears on the Monitor Alternate Routes screen, 
since this value is given on a system basis. 

• The Messages Sent and Messages Received fields that appear on the 
CNSMGR Summary screen display slightly different information than 
what is displayed by summing these same fields on the detailed 
Transport screen for all transports. The Messages Sent field on 
the Summary screen does not include rejected messages while the 
Messages Sent field on the Transport screen does. In addition, 
the Messages Received field on the Summary screen does not include 
pass-through messages while the Messages Received field on the 
Transport screen does. 

• Any Event Inguiry log message that is posted when an application 
detaches or a session completes contains byte and message counts 
that might not match the values given on the CNSMGR Monitor 
Application screen. Although CNS passes this information to both 
Event Inquiry and CNSMGR while an application or session is 
active, after an application has detached or a session completes. 
Event Inquiry automatically receives the totals for byte and 
message counts, while CNSMGR does not. Following is a comparison 
of the byte and message counts that are given by Event Inquiry and 
CNSMGR. 

There are two Event Inquiry messages that display "Bytes 
Received/Sent" and "Messages Received/Sent:" 

Application Detached, Appl = XXX, User = XXX, Sessions In = 
nnn. Sessions Out = nnn. Messages In = nnn. Messages Out = nnn. 
Bytes In = nnn. Bytes Out = nnn. Subtask ID = nnn 

Session Terminated Normally, SID = nnn. User = XXX, Msgs In = 
nnn, Msgs Out = nnn. Bytes In = nnn. Bytes out = nnn, Rexmits 
Outs = nnn, Rexmits In = nnn, Rcvd out of seq = nnn 
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The values that Event Inquiry provides for byte and message counts 
are explained as follows: 

Bytes Received (Bytes In) -- Equals the final total of bytes 
received by the application or session at application detach or 
session termination time. 

Bytes Sent (Bytes Out) -- Equals the final total of bytes sent by 
the application or session at application detach or session 
termination time. 

Messages Received (Msgs In) — Equals the final total of messages 
received by the application or session at application detach or 
session termination time. 

Messages Sent (Msgs Out) — Equals the final total of ressages 
sent by the application or session at application detach or 
session termination time. 

The corresponding values for byte and message counts that appear 
on the CNSMGR Monitor Application Status screen are as follows: 

Bytes Received -- Equals the sum of the bytes received by the 
application or session at the time that the request for the 
statistic information was made. 

Bytes Sent — Equals the sum of bytes sent by the application or 
session at the time that the request for statistic information was 
made. 

Messages Received — Equals the sum of the messages received by 
the application or session at the time that the request for 
statistic information was made. 

Messages Sent -- Equals the sum of the messages sent by the 
application or session at the time that the request for statistic 
information was made. 

• Occasionally, under heavy load, CNS Manager operations will halt 
so that resources can be diverted to more critical network 
operations. When sufficient resources are available, CNS Manager 
operations will resume. 
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CONDITIONS 


o 


The following conditions describe potential problems or situations 
that can occur with the operation and administration of WSN VS 
networking software. You should be aware of these conditions in order 
to avoid or minimize their effects. 


General 

• When using Release 1.01.01 of the WSN 802.3 transport, the 802.3 
protocol stack can detect errors (e.g., lost packets) but it 
cannot correct them. This is not a problem for applications using 
CNS because of the error recovery function. However, for this 
reason, non-CNS applications (such as, @ATTACH@) are not supported 
over Release 1.01.01 of the 802.3 transport. 

• Only one WSN 802.3 transport can be configured per DLP address. 
Configuration of two, even if one or both are disabled, will cause 
errors when enabling of the transport is attempted and prohibit 
CNS use of the transport. 

• You cannot reinitialize and reload transport microcode to a data 
link processor (DLP) by inhibiting and then reallowing services on 
a transport. In past releases, this operation was supported 
through a combination of Operator Communications functions and 
disabling the transport and then reallowing services on the 
transport by reversing these steps. 

A future release of the VS operating system will eliminate this 
condition. Until you have this release installed on your system, 
if you need to reinitialize and reload a DLP, you can either 
initial program load (reset) the DLP or initial program load the 
VS. If you need to perform this operation on a frequent basis, 
consult a Wang analyst for a program that can be used to 
circumvent this condition. 

• When 80 to 100 simultaneous remote logons are initiated to one 
local VS while there are 20 to 30 local workstations active on 
that VS, @RMTIPC@ can become detached from CNS, causing these 
remote logons to fail. When this occurs, @RMTIPC@ will reattach 
to CNS but the logon will have to be reinitiated by the remote 
user. 

• When communicating with an IDS host over an IDS 3271 BSC or 3274 
SNA transport, if the IDS host issues a link disable, the VS 
subtask for this transport remains active. The status appears as 
"Enable Fail" at the VS, and results in a maximum of 27, not 28, 
other transports that can be enabled at the VS. Similarly, if the 
disabling of the transport at the VS does not complete 
successfully, the VS subtask remains active, reducing the maximum 
allowed number of enabled transports by one. 
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Event Inquiry 


• Event Inquiry displays some unreadable status messages from Wang 
OFFICE and PDS Store and Forward managers, which should be ignored. 

• On a moderately- to heavily-loaded system. Event Inquiry may 
report "084-TIMEOUT FROM LOGTSK" intermittently. During this 
time, some of the messages that should be written to the log file 
are lost. CNS discards log messages during these periods but will 
log this occurrence the next time it is able to communicate with 
LOGTSK. 

These incidences can be reduced by limiting all foreground and 
background tasks that log messages to the logger, or that read 
from the log files, to only those that are necessary. If running 
Event Inquiry, increase the update period to a minimum of 15 
seconds and ensure that the most recent screen is displayed by 
respecifying system and subsystem parameters. 

• When another task (such as a user running DISPLAY) is accessing 
the log file at the same time that LOGTSK is submitted, a LOGTSK 
dump occurs with the message 

019 Unable to Access Today’s Logfile: Possession Conflict. 

No action is required when this conflict occurs since LOGTSK is 
automatically resubmitted immediately, and again every ten (10) 
minutes until normal functioning resumes. 

• Log messages sometimes appear truncated in Event Inquiry. 


CNS Manager 

• Occasionally, the CNS Manager (CNSMGR) displays a partial screen. 
When this occurs, exit and then return to the screen. 

• For performance reasons, CNS status is only checked when screen 
transitions occur. Also, statistics are updated only when the 
update interval expires. If CNS goes from inactive to active 
while a lower level screen (e.g.. Monitor Applications) is 
displayed, CNSMGR will not immediately update statistics upon 
returning to the higher level screen (e.g.. Select Application or 
Session to Monitor ). At this point if you want to view current 
statistics you can either press ENTER or wait till the update 
interval expires. 

• Occasionally, the screens file causes loss of user-entered 
characters (i.e., nonblank characters used to select operations). 
Reenter the missing characters when this occurs. 
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• After reaching a maximum of 100 trace files, CNS starts to reuse 
these trace files by appending them rather than by creating new 
files. Thus, to insure that new files have the correct assigned 
attributes, it is recommended that you delete old files before 
they reach the maximum limit of 100. 

• Occasionally, the Find function (PF8) for the Monitor Adjacent 
System screen does not locate the specified system. 

• The Detailed Transports screen may occasionally show an undefined 
CNS code 48 or 49 under the Status Reason field for 802.3 or 
WangPac transports. This condition requires no action. 

• The Path Trace Result screen incorrectly shows transport failure 
reason "Unknown System" when path trace is directly issued from 
one multipoint secondary to another. This condition requires no 
action. 

• If a CNS timeout occurs, the first application that appears on the 
Applications or Sessions screen may be scrambled. If this occurs, 
exit and then rerun CNSMGR. 

• CNS Start time is not displayed correctly if CNS becomes active 
while the user is running Alerts, Event Inquiry, or the Diagnostic 
tests. To view the correct Start time, exit and then rerun CNSMGR. 

• When creating a new CNSLOG file from the CNS Trace facility, the 
previous, not current, selected block allocation is used. Thus, 
at times, it may appear that there is insufficient space to create 
a file. To check this, rerun the CNS Trace facility using the 
same parameters. 

• The CNS Trace message, "FAILURE: Could not open log file on 
selected volume," is displayed when the volume contains 
insufficient space for the file size specified. When this occurs, 
you can reduce the file size to continue operations. 

• Occasionally, the Select CNS Transports for Management screen 
displays scrambled names of the first and last transports listed. 
When this occurs, exit and then rerun CNSMGR. 

• On the Path Trace Results screen, the Local CNS Version Number is 
incorrectly listed as the Destination CNS Version Number. 

• Following each restart of CNS, Path Trace reports success to a 
system over 802.3 that is not configured on the 802.3 link. 
Subsequent path traces report correctly. 
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CHAPTER 4 
MEDIA CONTENTS 


INTRODUCTION 

This chapter provides a list and brief description of the files 
contained in Release 8.32.03 of WSN VS NETCORE. Although WSN VS 
NETCORE is installed by Wang customer support personnel, the media 
contents are described here as an aid for network administrators. 

The WSN VS NETCORE package can be ordered in a variety of media types 
to accommodate your particular disk drive requirements. The media 
type designations for each of the media types supported are listed as 
follows: 

(-3) — An 8-inch, single-sided, single-density diskette 
(-5) -- An 8-inch, double-sided, double-density diskette 
(-9) — A 5 1/4-inch, double-sided, double-density diskette 

MEDIA CONTENTS 

Table 4-1 lists the files contained in WSN VS NETCORE, Release 
8.32.03. Once installed, these files reside in the NETCORE output 
library called @SYSC0M@. (Refer to the note that appears in the 
section called "Displaying NETCORE Version Numbers.") 


Note: Use the following legend to determine which files in Table 4-1 
are mandatory , and which files are optional , for installation on the 
VS. Files listed as optional or as not mandatory for your system can 
be stored off-line to free up system disk space and consequently ease 
memory restrictions on your system. 
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Code Meaning 
M Mandatory file 

MC Mandatory file when CNS is installed 

MX Mandatory file if remote logon (VSTE) or File Transfer is used 

MI Mandatory file when networked PC systems (Intelligent 
Workstations) are installed 
0 Optional file 

ORC Optional recommended file when CNS is installed 

S Installation or configuration file that can be stored off-line 


Table 4-1. WSN VS NETCORE Program Files 


File 

Protect. 

Class 

Version 

Blocks 

Alloc. 

Code 

Description 

SCMCNSUB 


01 . 00.00 

1 

MI 

Procedure for CNS to use to 
start @CNXMGR@. 

$CMSTART 


01 . 00.00 

1 

MI 

Procedure to run CMSTART. 

$CMSTOP$ 


01 . 00.00 

1 

MI 

Procedure to run CMSTOP. 

$MCPSAMP 

$ 

01 . 00.00 

1 

S 

Sample procedure for IDS 

Bisync transports, used by 
CNFGAID. 

$CNXMGR$ 


01 . 00.00 

1 

MI 

Procedure to submit 

Connection Manager. 

@CNXMGR@ 

0 

01.00.19 

491 

MI 

Connection Manager. 

@EVTINQ@ 

0 

02.02.01 

172 

M 

Program to monitor log 
entries in log file. 

Entries are written by 

LOGTSK. 

@RATGATE 

@ 

07.15.08 

122 

M 

Remote VS Logon access task. 

@RMTIPC@ 

@ 

02.19.09 

168 

M 

Remote interprocess task. 

@SESMGR7 

@ 

08.00.35 

147 

M 

Session Manager. 

APPSCRN 

$ 

01 . 00.00 

25 

M 

Screen file associated with 
WSNAPPS. 

CMSTART 


01.00.03 

157 

MI 

Startup program for Connection 
Manager. 


(continued) 
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Table 4-1. WSN VS NETCORE Program Files (continued) 


File 

— 

Protect. 

Class 

Version 

— 

Blocks 

Alloc. 

Code 

Description 

CMSTOP 

@ 

01.00.02 

2 

MI 

Halt program for Connection 
Manager. 

CNFGAID 


01.03.06 

10 

s 

Procedure to lead 
administrator through 
configuration. j 

CNS 

@ 

04.01.04 

429 

MC 

CNS Network Access Task j 

(NAT). j 

i 

CNS#AFP 


01.00.14 

192 

MC 

I 

CNS Manager foreground i 

program. 1 

CNS#INST 


01.00.01 

1 

S 

CNS Manager installation • 

procedure. j 

CNS#MSG2 


01.00.08 

52 

MC 

: 

CNS Manager screen file. 1 

i 

CNSMGR 


01.00.01 

40 

MC 

CNS Manager program to run 
CNS#AFP in standalone mode. ! 

CNSEND 

<§ 

01.00.00 

13 

MC 

Program to terminate CNS 
task. 

; 

CONECTST 

@ 

01.04.06 

233 

ORC 

. . « 
Network connectivity 

diagnostic. 

DIRPTR 


o 

to 

o 

o 

o 

22 

s 

Utility to display/set 
location of the directory. 

DTFORMS 


01.03.00 

21 

ORC 

Diagnostic tools forms file. 

EVENTINQ 

@ 

02.02.00 

1 

M 

Procedure that runs @EVTINQ@ 
in foreground. 

EVTFORMS 

$ 

000042 

29 

M 

Forms file for @EVTINQ@ 
program. 

IDTEST 

@ 

01.00.00 

1 

MI 

Password validation routine 
for Connection Manager. 

INSREML 

<§ 

01.00.09 

2 

S 

_J 

Procedure to install remote 
access files. 

' (continued] 
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Table 4-1. WSN VS NETCORE Program Files (continued) 


File 

Protect. 

Class 

Version 

Blocks 

Alloc. 

Code 

! 

i 

Description • 

INSTALL 


08.32.03 

5 

S 

Procedure to install the 
software, used initially or i 

after the library has been 
moved to another volume. 

LOG0INST; @ 

i 

i 

01.00.14 

3 

S 

Procedure initially used to 
install the logger files. 1 

i 

LOGCNTRL 

e 

03.02.08 

10 

M 

Program to set the location 
of the log file, required 
during installation and 
reinstallation. 

LOGEND 


02.02.01 

2 

M 

Program to terminate log 
background tasks. 

LOGMSGFL 


00.02 

13 

M 

Logger message and operator 
message file used by Session 

Manager. j 

! 

LOGTSK 


03.03.31 

38 

M 

Background task to read and j 
write the current day’s log 
file. I 

PASSBKGD 

@ 

01 . 00.00 

1 

ORC 

Procedure to run PASSTEST in 
the background. 

PASSTEST 


01.01.05 

75 

ORC 

Passive counterpart for all 
diagnostics. 

PROCRUN 

@ 

01.00.01 

4 

S 

Generates procedures in 
@SYSTEM@ to run programs in 
@SYSC0M@. 

PROPTEST 


01.04.04 

184 

0 

Propagation delay diagnostic. 

RGSUBMIT 

e 

07.15.08 

8 

M 

Procedure to submit 0RATGATE. 

RIPCEND 

@ 

02.11.00 

1 

MC 

Program to terminate 
@RMTIPC@. 

RLGSTART 


03.00.00 

i 

M 

Procedure to submit @RATTSK@ 
and 0RATGATE. 


(continued) 
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Table 4-1. WSN VS NETCORE Program Files (continued) 




File 

Protect. 

Class 

Version 

Blocks 

Alloc. 

Code 

Description 

RLGSTOP 

@ 

02.00.00 

1 

M 

Procedure to terminate 
<?RATTSK@ and @RATGATE. 

RTGCALC 

@ 

01.00.00 

1 

S 

Procedure to change number of 
remote users supported. 

RTGEND 

<3 

07.15.08 

1 

M 

Program to terminate 

0RATGATE. 

RTGSTART 

@ 

02.00.00 

1 

M 

Procedure to submit 0RATGATE. 

RTGSTOP 


01.00.00 

1 

M 

Procedure to terminate 
@RATGATE. 

SYNCTEST 


01.04.06 

188 

0 

Synchronous pattern 
diagnostic. 

THRUTEST 


01.03.05 

185 

0 

Throughput diagnostic. 

WSNAPPS 


01.00.00 

63 

0 

Application record 
maintenance. 

WSNDIRI 

@ 

02.02.03 

m 

s 

i 

Directory maintenance 
utility. 

WSNDIRM 


01.00.01 

1 

s 

Procedure to run WSNDIRI. 

I 

WSNEDIT 

@ 

08.10.20 

301 

s 

Configuration editor. 

WSNEDT2 

e 

08.10.20 

282 

S 

Configuration editor. 

WSNINPT 

<3 

08.10.20 

95 

s 

Configuration file input and 
conversion used during 
installation/reinstallation. 

WSNPRT 

<§ 

01.00.17 

_ . 

167 

0 

WSN Configuration Reporter. 

_ __ 


(continued) 


r*\ 
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Table 4-1. WSN VS NETCORE Program Files (continued) 




File 

Protect. 

Class 

Version 

Blocks 

Alloc. 

Code 

! 

Description 

WSNREORG 

S 

-— - 

01.01.01 

14 

M 

Procedure used to reorganize 
the network and Wang OFFICE j 

directory. 

WSNSTART 

S 

01.00.20 

2 

M 

Procedure used to submit ! 

background tasks for all ! 

installed networking 
software. 

WSNSTOP 

@ 

01.00.16 

2 

M 

Procedure used to terminate 
background tasks for 
installed networking 
software. 

- - -_ 


DISPLAYING WSN VS NETCORE VERSION NUMBERS 

This section gives the procedures for finding the version number of any 
of the files that are released with WSN VS NETCORE. Following 
installation, the libraries containing these files are SSYSCOMS and 
@SYSTEMS. 


Note: the name given to the output library (represented here as 
@SYSCOM@) can be modified. OSYSCOMO is generally used to designate the 
NETCORE output library: however, if you specified another name for the 
output library during WSN VS NETCORE installation, you must enter this 
name for the output library and specify the correct volume when using 
the DISPLAY utility . 
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The filenames and associated display procedures are listed as follows: 

Library @SYSCOM@ 








INSTALL 

-- 

Run 

procedure and look at first screen. 



PROCRUN 

-- 

Run 

DISPLAY 

and display 

the 

fourth 

l record. 



WSNREORG 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



WSNSTART 

— 

Run 

DISPLAY 

and display 

the 

first 

record. 



WSNSTOP 

— 

Run 

DISPLAY 

and display 

the 

first 

record. 



CNS 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



@CNXMGR@ 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



0SESMGR7 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



CMSTART 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



CMSTOP 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



IDTEST 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



CNSEND 

— 

Run 

DISPLAY 

and display 

the 

first 

record. 



IDTEST 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



CONECTST 

— 

Run 

the program. The version number is on 

the 

first 

DTFORMS 

-- 

Run 

DISPLAY 

and search for : 

record 

"ZZZZ." 



PASSBRGD 

-- 

Run 

DISPLAY 

and display 

the 

first 

record. 



PASSTEST 

-- 

Run 

DISPLAY 

and find the 

i text string "PASSTEST 

REV." 

PROPTEST 

— 

Run 

the program. The version number is on 

the 

first 

SYNCTEST 

— 

Run 

the program. The version number is on 

the 

first 

THRUTEST 

— 

Run 

the program. The version number is on 

the 

first 

SMCPSAMP 

— 

Run 

DISPLAY 

and display 

the 

first 

record. 



APPSCRN 

— 

Run 

DISPLAY 

and display 

the 

first 

record. 



CNFGAID 

— 

Run 

procedure and look at first screen. 



DIRPTR 

— 

Run 

the program. The version number is on 

the 

first 

WSNAPPS 

— 

Run 

the program. The version number is on 

the 

first 


screen 


screen 

screen 

screen 


screen 

screen 
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WSNDIRI — Run DISPLAY and display the first record. 

WSNDIRM — Run DISPLAY and display the first record. 

WSNEDIT — Run program and look at first screen. 

WSNEDT2 — Run DISPLAY and display the first record. 

WSNINPT -- Run DISPLAY and display the first record. 

WSNPRT — Run the program and look at the first screen. 


Library ©SYSTEM® 


$CNXMGR$ -- Run DISPLAY 
$CMSTART -- Run DISPLAY 
$CMSTOP$ — Run DISPLAY 
$CMCNSUB — Run DISPLAY 
CNS#INST — Run DISPLAY 
CNS#MSG2 — Run DISPLAY 
CNSMGR — Run DISPLAY 
CNS#AFP — Run DISPLAY 
@RATGATE -- Run DISPLAY 
@RMTIPC@ — Run DISPLAY 
INSREML — Run DISPLAY 
RGSUBMIT — Run DISPLAY 
RIPCEND — Run DISPLAY 
RLGSTART — Run DISPLAY 
RLGSTOP — Run DISPLAY 
RTGCALC — Run DISPLAY 
RTGEND -- Run DISPLAY 
RTGSTART — Run DISPLAY 
RTGSTOP — Run DISPLAY 


and display first record, 
and display first record, 
and display first record, 
and display first record, 
and search for CNS0INST." 
and search for "##CNS#MSG2." 
and search for "##CNSMGR." 
and search for M ##CNS#AFP." 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record, 
and display first record 


J 






r\ 
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Note: The following files are generally located in both library 
QSYSTEMQ on the System volume and library @SYSCOMQ on the WSN VS 
NETCORE installation volume. Unless otherwise specified, you can find 
the version numbers in either of these libraries. 


@EVTINQ@ -- Run EVENTINQ in @SYSCOM@ on install volume and look at top 
of first screen. Or, run DISPLAY and find the text string 
"##@EVTINQ." 

EVTFORMS -- Run DISPLAY and search for record "ZZZZ.” The first six 
(6) numbers (positions 15 through 20, inclusive) are the 
version number. 


LOG#INST — 

Run 

DISPLAY 

and 

look 

LOGCNTRL -- 

Run 

DISPLAY 

and 

find 

LOGEND 

Run 

DISPLAY 

and 

find 

EVENTINQ -- 

Run 

DISPLAY 

and 

look 

LOGTSK 

Run 

DISPLAY 

and 

find 
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Help Us Help You... 


Customer Comment Form Publication Number 

WANG SYSTEMS NETWORKING VS NETCORE 
Title_ RELEASE 8.32.03 CSRN 


We've worked hard to make this document useful, readable, and technically accurate. Did we succeed? Only you can tell us! 
Your comments and suggestions will help us improve our technical communications. Please take a few minutes to let us 
know how you feel. 


How did you receive this publication? 


How did you use this Publication? 


□ Support or □ Don't know 

Sales Rep 

□ Wang Supplies □ Other_ 

Division _ 

□ From another _ 

user _ 

□ Enclosed _ 

with equipment _ 


□ Introduction 
to the subject 

□ Classroom text 
(student) 

□ Classroom text 
(teacher) 

□ Self-study 
text 


□ Aid to advanced 
knowledge 

□ Guide to operating 
instructions 

□ Asa reference 
manual 

□ Other_ 


Please rate the quality of this publication in each of the following areas. 

EXCELLENT 

GOOD 

FAIR 

POOR 

VERY 

POOR 

Technical Accuracy — Does the system work the way the manual says it does? 

□ 

□ 

□ 

□ 

□ 

Readability — Is the manual easy to read and understand ? 

□ 

□ 

□ 

□ 

□ 

Clarity — Are the instructions easy to follow? 

□ 

□ 

□ 

□ 

□ 

Examples — Were they helpful, realistic? Were there enough of them? 

□ 

□ 

□ 

□ 

□ 

Organization — Was it logical? Was it easy to find what you needed to know? 

□ 

□ 

□ 

□ 

□ 

Illustrations — Were they clear and useful? 

□ 

□ 

□ 

□ 

□ 

Physical Attractiveness — What did you think of the printing, binding, etc? 

□ 

□ 

□ 

□ 

□ 

Were there any terms or concepts that were not defined properly? DY ON 

If so, what were they?. 





After reading this document do you feel that you will be able to operate the equipment/software? □ Yes □ No 

□ Yes, with practice 


What errors or faults did you find in the manual? (Please include page numbers) 


Do you have any other comments or suggestions? 


Name_ Street_ 

Title_ City_ 

Dept/Mail Stop_ State/Country_ 

Company_ Zip Code_Telephone 

Thank you for your help. 


All comments and suggestions become the property of Wang Laboratories, Inc. 


Printed in U.S.A. 14-3140A 2-88 
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To Order by Phone, Call: 

1-(800)225-0234 
Telex 172108 





Order Form for Wang Manuals and Documentation 

0 Customer Number (If Known) 


©Bill To: Ship To: 


0 Customer Contact: ©Date Purchase Order Number 

J_L_<_)__ 

Phone_Name_ 


©Taxable ©Tax Exempt Number ©Credit This Order to 

Yes □ A Wang Salesperson-1_ 

No □_Please Complete Salesperson’s Name Employee No. RDB No. 


© Document Number 

Description 

Quantity 

© Unit Price 

Total Price 































© 

Sub Total 


Authorized Signature Date 

□ Check this box if you would like a free copy of 

WangDirect Software & Literature Catalog 

(711-0888A) 

Less Any 

Applicable 

Discount 


Sub Total 


LocalStateTax 


Total Amount 





Ordering Instructions 

1. If you have purchased supplies from Wang before, and 
know your Customer Number, please write it here. 

2. Provide appropriate Billing Address and Shipping Address. 

3. Please provide a phone number and name, should it be 
necessary for WANG to contact you about your order. 

4. Your purchase order number and date. 

5. Show whether order is taxable or not. 

6. If tax exempt, please provide your exemption number. 

Wang Terms and Conditions 

1. TAXES — Prices are exclusive of all sales, use, and like 
taxes. 

2. DELIVERY — Delivery will be F O B. Wang's plant. 
Customer wilt be billed lor freight charges; and unless 
customer specifies otherwise, all shipments will go best 
way surface as determined by Wang. Wang shall not 
assume any liability in connection with the shipment nor 
shall the carrier be construed to be an agent of Wang. 

If the customer requests that Wang arrange for insurance 
the customer will be billed for the insurance charges. 


7. If you wish credit for this order to be given to a WANG 
salesperson, please complete. 

8. Show part numbers, description and quantity for each 
product ordered. 

9 Pricing extensions and totaling can be completed at your 
option: Wang will religure these prices and add freight on 
your invoice. 

10. Signature of authorized buyer and date. 


3. PAYMENT — Terms are net 30 days from date of invoice. 
Unless otherwise stated by customer, partial shipments will 
generate partial invoices. 

4. PRICES — The prices shown are subject to change without 
notice. Individual document prices may be found in the 
WangDirect Software & Literature Catalog (711-0888A) 

5. LIMITATION OF LIABILITY - In no event shall Wang be liable 
for loss of data or for special, incidental or consequential 
damages in connection with or arising out of the use of or 
information contained in any manuals or documentation 
furnished hereunder 


Printed in U S A 14-3141A 2-88 
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ONE INDUSTRIAL AVENUE, LOWELL, MA 01851 
TEL. (508) 459-5000, TELEX 172108 



